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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 
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Copyright (C) The Internet Society (2003). All Rights Reserved. 


Abstract 


This document describes the multiappending extension to the Internet 
Message Access Protocol (IMAP) (RFC 3501). This extension provides 
substantial performance improvements for IMAP clients which upload 
multiple messages at a time to a mailbox on the server. 


A server which supports this extension indicates this with a 
capability name of "MULTIAPPEND". 


Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in [KEYWORDS]. 


Introduction 


The MULTIAPPEND extension permits uploading of multiple messages with 
a single command. When used in conjunction with the [LITERAL+] 
extension, the entire upload is accomplished in a single 
command/response round trip. 


A MULTIAPPEND APPEND operation is atomic; either all messages are 
successfully appended, or no messages are appended. 


In the base IMAP specification, each message must be appended in a 


separate command, and there is no mechanism to "unappend" messages if 
an error occurs while appending. Also, some mail stores may require 
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an expensive "open/lock + sync/unlock/close" operation as part of 
appending; this can be quite expensive if it must be done ona 
per-message basis. 


If the server supports both LITERAL+ and pipelining but not 
MULTIAPPEND, it may be possible to get some of the performance 
advantages of MULTIAPPEND by doing a pipelined "batch" append. 
However, it will not work as well as MULTIAPPEND for the following 
reasons: 


1) Multiple APPEND commands, even as part of a pipelined batch, 
are non-atomic by definition. There is no way to revert the 
mailbox to the state before the batch append in the event of an 
error. 


2) It may not be feasible for the server to coalesce pipelined 
APPEND operations so as to avoid the "open/lock + 


sync/unlock/close" overhead described above. In any case, such 
coalescing would be timing dependent and thus potentially 
unreliable. In particular, with traditional UNIX mailbox files, 


it is assumed that a lock is held only for a single atomic 
operation, and many applications disregard any lock that is 
older than 5 minutes. 


3) If an error occurs, depending upon the nature of the error, 
it is possible for additional messages to be appended after the 
error. For example, the user wants to append 5 messages, but a 
disk quota error occurs with the third message because of its 
size. However, the fourth and fifth messages have already been 
sent in the pipeline, so the mailbox ends up with the first, 
second, fourth, and fifth messages of the batch appended. 


6.3.11. APPEND Command 


Arguments: mailbox name 
one or more messages to upload, specified as: 
OPTIONAL flag parenthesized list 
OPTIONAL date/time string 
message literal 


Data: no specific responses for this command 


Result: OK - append completed 
NO - append error: can’t append to that mailbox, error 
in flags or date/time or message text, 
append cancelled 
BAD - command unknown or arguments invalid 
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The APPEND command appends the literal arguments as new messages 
to the end of the specified destination mailbox. This argument 
SHOULD be in the format of an [RFC-2822] message. 8-bit 
characters are permitted in the message. A server implementation 
that is unable to preserve 8-bit data properly MUST be able to 
reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB] 
content transfer encoding. 


Note: There MAY be exceptions, e.g., draft messages, in 
which required [RFC-2822] header lines are omitted in the 
message literal argument to APPEND. The full implications 
of doing so MUST be understood and carefully weighed. 


If a flag parenthesized list is specified, the flags SHOULD be set 
in the resulting message; otherwise, the flag list of the 
resulting message is set empty by default. 


If a date-time is specified, the internal date SHOULD be set in 
the resulting message; otherwise, the internal date of the 
resulting message is set to the current date and time by default. 


A zero-length message literal argument is an error, and MUST 
return a NO. This can be used to cancel the append. 


If the append is unsuccessful for any reason (including being 
cancelled), the mailbox MUST be restored to its state before the 
APPEND attempt; no partial appending is permitted. The server MAY 
return an error before processing all the message arguments. 


If the destination mailbox does not exist, a server MUST return an 
error, and MUST NOT automatically create the mailbox. Unless it 
is certain that the destination mailbox can not be created, the 
server MUST send the response code "[TRYCREATE]" as the prefix of 
the text of the tagged NO response. This gives a hint to the 
client that it can attempt a CREATE command and retry the APPEND 
if the CREATE is successful. 


If the mailbox is currently selected, the normal new message 
actions SHOULD occur. Specifically, the server SHOULD notify the 
client immediately via an untagged EXISTS response. If the server 
does not do so, the client MAY issue a NOOP command (or failing 
that, a CHECK command) after one or more APPEND commands. 
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A003 APPEND saved-messages (\Seen) {329} 

+ Ready for literal data 

Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 

From: Fred Foobar <foobar@Blurdybloop.example.COM> 
Subject: afternoon meeting 

To: mooch@owatagu.example.net 

Message-Id: <B27397-0100000@Blurdybloop.example.COM> 
MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 


Example: 


Hello Joe, do you think we can meet at 3:30 tomorrow? 
(\Seen) " 7-Feb-1994 22:43:04 -0800" {295} 

+ Ready for literal data 

Date: Mon, 7 Feb 1994 22:43:04 -0800 (PST) 

From: Joe Mooch <mooch@OWaTaGu.example.net> 

Subject: Re: afternoon meeting 

To: foobar@blurdybloop.example.com 

Message-Id: <a0434793874930@OWaTaGu.example.net> 
MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 


3:30 is fine with me. 


A003 OK APPEND completed 
A004 APPEND bogusname (\Flagged) {1023} 
A004 NO [TRYCREATE] No such mailbox as bogusname 
A005 APPEND test (\Flagged) {99} 
+ Ready for literal data 
Date: Mon, 7 Feb 2000 22:43:04 -0800 (PST) 
From: Fred Foobar <fred@example.com> 
Subject: hmm... 
{35403} 
A005 NO APPEND failed: Disk quota exceeded 


NMQAQAQAM_ANAWMNANQAaAaQaNQaAaaQaganaadaaanagaaagnaanna 


Note: The APPEND command is not used for message delivery, 
because it does not provide a mechanism to transfer [SMTP] 
envelope information. 


Modification to IMAP4revl Base Protocol Formal Syntax 


The following syntax specification uses the Augmented Backus-Naur 
Form (ABNF) notation as specified in [ABNF]. 


append = "APPEND" SP mailbox 1*append-message 


append-message [SP flag-list] [SP date-time] SP literal 
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MULTIAPPEND Interaction with UIDPLUS Extension 


Servers which support both MULTIAPPEND and [UIDPLUS] will have the 
"resp-—code-apnd" rule modified as follows: 


resp-code-apnd = "APPENDUID" SP nz-number SP set 


That is, the APPENDUID response code returns as many UIDs as there 
were messages appended in the multiple append. The UIDs returned 
should be in the order the articles where appended. The message set 
may not contain extraneous UIDs or the symbol "*". 


Security Considerations 


The MULTIAPPEND extension does not raise any security considerations 
that are not present in the base [IMAP] protocol, and these issues 
are discussed in [IMAP]. Nevertheless, it is important to remember 
that IMAP4revl protocol transactions, including electronic mail data, 
are sent in the clear over the network unless protection from 
snooping is negotiated, either by the use of STARTTLS, privacy 
protection is negotiated in the AUTHENTICATE command, or some other 
protection mechanism is in effect. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2003). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Acknowledgement 


Funding for the RFC Editor function is currently provided by the 
Internet Society. 


Crispin Standards Track [Page 7] 


